In the field of this invention it is known that hardware architecture of data storage subsystems changes frequently. It is well known that the management software required for such subsystems is typically complex, resulting in lengthy and involved software development and ongoing software maintenance which is similarly problematic.
In addition to this, changes to subsystem hardware inevitably require changes to the management software, for example, to support new features or to change the capabilities of existing features. Compatibility issues arise between mismatches of software and hardware and these are difficult to resolve. Hence costly rebuilds of these management software tools are required whenever a change occurs in the hardware.
Older systems addressed these problems in a number of ways, such as the presence of large amounts of otherwise unnecessary source code in the software. This also has the problem that every time a restriction is required/changed the source code had to be modified, recompiled and tested again before release.
Furthermore, many computer data storage subsystems now provide ‘enhanced’ features that provide functions other than standard Input/Output (I/O) operations. By their very nature, these features provide complex manipulation of raw data held on magnetic media or in non-volatile memory. For example a feature such as a point in time copy (FlashCopy) allows a user to copy an entire/part of a file system from one logical resource to another.
In previous subsystems users were not hidden from the underlying stacked logical resources (there were typically only 2 or 3) and this level of complexity was reasonable to expose to the user. In present subsystems there may be 7 or 8 logical resources, which would be unreasonably complex for a user, so a ‘logical to object’ relationship is created, which requires a certain amount of software complexity. In this way the management software handles the complexity of multiple logical resources, rather than the user.
Another approach taken in older systems is known as ‘View/Data/Action definitions’. This requires all the resource details to be hard-coded in the source code. There is no ‘inheritance’, so each type of logical resource has to be defined in source code with respect to the views, data and actions available to them.
The increased complexity of ‘next generation’ storage subsystems and the proliferation of logical resources and features has therefore exacerbated this problem.
A need therefore exists for a computer storage subsystem, method, software program and data carrier wherein the abovementioned disadvantages may be alleviated.